干货|携程监控系统Hickwall演进之路

作者简介

大伟&＃xff0c;携程软件技术专家&＃xff0c;关注企业级监控&＃xff0c;日志&＃xff0c;可观测性领域。

一、背景

监控领域有三大块&＃xff0c;分别是Metrics&＃xff0c;Tracing&＃xff0c;Logging。这三者作为IT可观测性数据的三剑客&＃xff0c;基本可以满足各类监控、告警、分析、问题排查等需求。

Logs&＃xff1a;我们对于Logs是更加宽泛的定义&＃xff0c;即记录事物变化的载体&＃xff0c;包括常见的访问日志、交易日志、内核日志等文本型以及GPS、音视频等泛型数据。日志在调用链场景结构化后其实可以转变为Trace&＃xff0c;在进行聚合、降采样操作后会变成Metrics。

Metrics&＃xff1a;是聚合后的数值&＃xff0c;相对比较离散&＃xff0c;一般有name、labels、time、values组成&＃xff0c;Metrics数据量一般很小&＃xff0c;相对成本更低&＃xff0c;查询的速度比较快。

Traces&＃xff1a;是最标准的调用日志&＃xff0c;除了定义调用的父子关系外&＃xff08;一般通过TraceID、SpanID、ParentSpanID&＃xff09;&＃xff0c;一般还会定义操作的服务、方法、属性、状态、耗时等详细信息&＃xff0c;通过Trace能够代替一部分Logs的功能&＃xff0c;通过Trace的聚合也能得到每个服务、方法的Metrics指标。

近年来&＃xff0c;可观测性这个概念如火如荼&＃xff0c;可以看作是对监控的一次大升级。CNCF也发布了OpenTelemetry标准&＃xff0c;旨在提供可观测性领域的标准化方案。那么相比传统的监控告警&＃xff0c;监控和可观测性有啥区别和联系呢&＃xff1f;个人理解&＃xff0c;可观测性能够以更加白盒的方式看透整个复杂的系统&＃xff0c;帮助我们更好的观察系统的运行状况&＃xff0c;快速定位和解决问题。

简单理解&＃xff0c;监控和可观测性的关系。监控告诉我们系统的哪些部分是正常工作的&＃xff0c;可观测性告诉我们那里为什么不工作了。监控侧重宏观&＃xff0c;可观测性包括微观能力。监控是可观测性的子集。

图1

近些年&＃xff0c;随着携程集团对线上故障1-5-10目标的提出&＃xff08;即第1分钟发现故障&＃xff0c;第5分钟定位故障&＃xff0c;第10分钟解决故障&＃xff09;&＃xff0c;对监控系统提出了更高的要求。监控系统最重要的三个特点可以定义为&＃xff0c;系统稳定性&＃xff0c;数据及时性&＃xff0c;数据精准性&＃xff0c;三者缺一不可。

携程监控系统 Hickwall 是一个企业级的指标监控告警系统&＃xff0c;兼容了业界的 Prometheus监控标准&＃xff0c;覆盖携程所有的指标监控数据&＃xff0c;包括系统层和应用层。主要目标是实现指标数据的采集、接入、存储、展现&＃xff0c;并在此基础上配置告警和通知&＃xff0c;告警治理等&＃xff0c;同时为第三方平台提供第一手的监控数据和告警事件。

二、遇到的问题

随着业务不断膨胀&＃xff0c;系统规模的持续扩大&＃xff0c;Hickwall遇到了一些问题&＃xff1a;

• 高基数查询&＃xff0c;指标维度过多&＃xff0c;导致整体查询慢&＃xff0c;用户体验不佳。

• 云原生的监控方案缺乏&＃xff0c;需要支持开源PromQL业界标准&＃xff0c;Prometheus SDK指标接入。

• 监控粒度粗&＃xff0c;一些毛刺无法洞察&＃xff0c;需要提高数据采样粒度。

• 告警系统多&＃xff0c;技术方案杂&＃xff0c;难维护&＃xff0c;产品使用上用户到处找入口&＃xff0c;规则和阈值定义不一样&＃xff0c;很困惑。

• 监控数据延迟&＃xff0c;导致误告警。

• 告警多&＃xff0c;重复告警&＃xff0c;缺乏治理。

• 容器大规模HPA带来的指标基数膨胀问题。

三、主要的演进

针对上述问题和痛点&＃xff0c;Hickwall过去两年进行了一些针对性的优化和演进。

3.1 云原生监控

1&＃xff09;TSDB升级&＃xff0c;经过三次演进&＃xff0c;现在是基于VictoriaMetrics实现的第四代的TSDB解决方案。完全兼容Prometheus查询语法。

2&＃xff09;提供了自研Beacon容器监控组件&＃xff0c;和k8s体系高度集成&＃xff0c;不仅支持容器系统指标&＃xff0c;JVM指标&＃xff0c;也支持自定义的PrometheusSDK埋点接入。

3.2 解决高基数问题

1&＃xff09;产品升级&＃xff0c;新增日志/指标预聚合能力&＃xff0c;产品开放配置能力&＃xff0c;根据一定配置策略&＃xff0c;通过将多维原始数据降维&＃xff0c;收敛指标维度&＃xff0c;聚合输出预聚合数据&＃xff0c;通过这种方式可以缩减指标量级&＃xff0c;对后续链路的处理都有性能提升。目前系统配置了166条聚合规则&＃xff0c;生成了209个指标。

2&＃xff09;指标治理&＃xff1a;监控统计指标维度&＃xff0c;应用维度的高基数检测&＃xff0c;对非法写入进行封禁。非法写入包括了tag的value使用了随机数&＃xff0c;字符内容超过256个字符&＃xff0c;指标名称使用了中文命名等。

3&＃xff09;容量规划&＃xff1a;做好集群的自监控&＃xff0c;进行妥善的容量规划&＃xff0c;主要是监控ts增长数量和datapoint数据量&＃xff0c;以应对日益增长的指标数据。

4&＃xff09;忽略有问题的tag&＃xff1a;治理平台能够按需配置ignore tag&＃xff0c;例如针对HPA场景下的应用埋点&＃xff0c;忽略value容易发生变化的hostname和ip这两种tag&＃xff08;一般不会关心这种维度&＃xff09;&＃xff0c;可以大大减少基数。

3.3 数据粒度提升

为了响应集团1-5-10目标&＃xff0c;核心指标采集上秒级&＃xff0c;目前主要涉及的是核心的系统指标&＃xff0c;业务订单指标和部分应用指标&＃xff0c;其他非关键可以按需自行配置。

3.4 告警中台接入

自研新一代统一的pull告警系统&＃xff0c;统一各类老的告警技术方案&＃xff0c;目前接入告警规则10万&＃43;&＃xff0c;同时对接了告警中心&＃xff0c;对用户提供一站式的告警治理能力。

3.5 解决数据延迟问题

数据延迟问题主要是数据链路还依赖了消费Kafka来写入TSDB。因此我们将核心链路改造成最短路径&＃xff0c;从数据网关分发数据直接写到TSDB&＃xff0c;从根本上解决了延迟问题。

3.6 时序存储的演进

Hickwall存储这块主要经历了下面四个阶段。

第一阶段&＃xff1a;ES存储&＃xff0c;Graphite查询语法

第一个版本的架构主要以数据写Kafka&＃xff0c;消费Kafka进ES的套路来设计。这个方案的好处&＃xff1a;

• 可以容忍比较大的系统downtime

• 数据可以多次多种方式加以利用

• ES存储的写入性能最大化

• ES的聚合能力比较强&＃xff0c;所以不少聚合都可以实时来做

• ES非常稳定可靠&＃xff0c;运维工作较少

第一个版本已经初步实现了监控系统的功能&＃xff0c;但是在使用过程中同样暴露了一些问题&＃xff1a;

1&＃xff09;ES存储导致数据容易堆积

ES是一个非常稳定的全文索引工具&＃xff0c;比较适合日志&＃xff0c;搜索的场景。但是却不是最好的监控数据的存储方式&＃xff0c;主要是写入性能不是很好&＃xff0c;必须大批量&＃xff0c;高等待的方式写才能达到比较大的量&＃xff0c;但是这个比较大的量相对监控数据的场景也略显不够。

而且为了提高写的性能&＃xff0c;还需要牺牲数据的实时性&＃xff08;提高refresh time来减少磁盘操作&＃xff0c;提高写入量&＃xff09;。实时性又是一个高质量的监控系统所需要努力提高的。这就是一个矛盾点&＃xff0c;虽然当时能够做到勉强接受&＃xff0c;但肯定不是最理想的&＃xff0c;当时的数据latency需要30s以上。

2&＃xff09;数据链路过长

监控数据主要是从Proxy进来到Trigger告警需要依次经过6个组件&＃xff0c;任何一个组件出现问题&＃xff0c;都可能导致告警漏告或误告。

第二阶段&＃xff1a;基于InfluxDB存储&＃xff0c;打造自研的Incluster集群方案&＃xff0c;Graphite查询语法

ES用于时间序列存储存在不少问题&＃xff0c;例如磁盘空间使用大&＃xff0c;磁盘IO使用多&＃xff0c;索引维护复杂&＃xff0c;写入和查询速度慢等。当时InfluxDB是排名第一的时序数据库&＃xff0c;到2017年的时候已经比较稳定&＃xff0c;所以我们萌生了用InfluxDB替换ES作为存储的方案。但是InfluxDB并没有开源的集群方案&＃xff0c;因此我们自研了Incluster集群方案。

在元数据管理这块使用了Raft来保证一致性和分区容错性。集群大致的实现思路是&＃xff0c;客户端通过Incluster节点写入数据&＃xff0c;Incluster按照数据分布策略将写入请求转发到相关的InfluxDB节点上&＃xff0c;查询的时候按照数据分布策略进行数据读取和合并。在用户查询方面&＃xff0c;实现了类Graphite语法用于配图&＃xff0c;兼容上一代语法&＃xff0c;从而可以减少用户迁移配图的成本。

第三阶段&＃xff1a;ClickHouse列式存储&＃xff0c;SQL查询语法

2019年&＃xff0c;我们逐步开始推进应用埋点存储的统一接入。在这个阶段&＃xff0c;InfluxDB在高基数场景下&＃xff0c;查询表现并不是很好&＃xff0c;集群稳定性也受到了较大的挑战。因此我们调研了当时大火的ClickHouse&＃xff0c;开始接入应用埋点&＃xff0c;并且提供SQL语法查询。携程的机票部门率先接入&＃xff0c;在自定义应用埋点场景取得了比较好的效果。

第四阶段&＃xff1a;基于开源的VictoriaMetrics TSDB&＃xff0c;PromQL查询语法

2020年&＃xff0c;随着云原生技术的发展&＃xff0c;内部对云监控的需求越来越强烈。因此我们在2020年调研并测试了业界开源的VictoriaMetrics TSDB&＃xff0c;这款TSDB作为Prometheus的远端持久存储解决方案&＃xff0c;提供了相较于传统TSDB较好的性能和天然兼容Prometheus协议的查询语法和接口。

这款TSDB经过测试在综合写入性能和查询方面表现较好。目前我们内部主要分了三个大集群&＃xff0c;集群规模已经达百余台物理机&＃xff0c;成为携程统一的Metrics存储方案。

图2

3.7 监控可视化的演进

由于内部使用的可视化工具是基于Grafana二次开发&＃xff0c;伴随着存储技术的升级&＃xff0c;2020年我们还进行了一次Grafana2版本到6版本的全面升级&＃xff0c;新版本增加了多种新的数据源&＃xff0c;所见即所得的告警能力&＃xff0c;更多的图表类型展现&＃xff0c;可视化方面大大提升了用户体验。

图3

四、平台现状

随着多年的发展&＃xff0c;目前平台指标数据量写入量峰值在千万级/秒&＃xff0c;查询量数千qps&＃xff0c;接入各类告警规则10万&＃43;&＃xff0c;查询P99控制在1s内。数据粒度最小支持到10s级&＃xff0c;时序数据默认保存一年。计算&＃43;存储集群规模达百余台物理机&＃xff0c;并且主要组件都上了k8s平台。数据统计如图4所示。

图4

五、目前架构

从数据流向看&＃xff0c;目前总体大致架构如图5所示&＃xff0c;可见数据流和告警是走的最短路径。

1&＃xff09;数据&＃xff1a;data->Proxy->TSDB

2&＃xff09;告警&＃xff1a;data->Proxy->Trigger

这从根本上规避数据延迟和告警延迟问题。下面会主要介绍Hickwall所依赖的几个核心组件。

图5

Collector组件&＃xff1a;

数据采集&＃xff0c;提供多种客户端&＃xff0c;包括了Hickwall SDK&＃xff08;应用埋点&＃xff09;&＃xff0c;Hickwall agent&＃xff08;机器数据采集&＃xff09;&＃xff0c;Prometheus SDK&＃xff0c;Beacon&＃xff08;容器数据采集&＃xff09;。

Proxy组件&＃xff1a;

提供给Hickwall SDK&＃xff0c;Hickwall agent&＃xff0c;Prometheus SDK的统一支持多协议的数据收集服务&＃xff0c;主要是thrift protocol和line protocol。作为数据接收的统一入口&＃xff0c;承担了流量接入&＃xff0c;分发&＃xff0c;流量保护&＃xff0c;数据统计等功能。Proxy默认为每个应用ID提供了固定的流量配额&＃xff0c;具备了基于指标&＃xff0c;应用ID的限流能力&＃xff0c;目前是基于固定时间窗口进行数据量流控。

告警组件&＃xff1a;

提供了Trigger流式告警和基于Bosun的统一pull告警。通过推拉结合的告警引擎解决了大规模阈值告警和复杂同环比告警场景。

DownSample组件&＃xff1a;

数据降采样&＃xff0c;支持可以配置的聚合采样粒度&＃xff0c;节省存储成本。同时提供数据保存更长的时间。

Piper组件&＃xff1a;

统一的告警通知服务&＃xff0c;支持告警通知升级。

Transfer组件&＃xff1a;

负责监控数据分发给第三方系统&＃xff0c;供数据分析&＃xff0c;容量规则&＃xff0c;AI智能告警等用途。

Grafana看板服务&＃xff1a;

所见即所得的查询&＃xff0c;提供丰富的图表展现以及监控大盘。

TSDB Cluster&＃xff1a;

是最核心的时序存储集群&＃xff0c;时序类的查询一般QPS都比较高&＃xff08;主要有很多告警规则&＃xff09;&＃xff0c;通常都是range查询&＃xff0c;每次查询某一个单一的指标/时间线&＃xff0c;或者一组时间线进行聚合。所以对于这类数据都会有专门的时序引擎来支撑&＃xff0c;目前主流的时序引擎基本上都是用类似于LSM Tree的思想来实现&＃xff0c;以适应高吞吐的写入和查询。

ClickHouse Cluster&＃xff1a;

ClickHouse作为优秀的OLAP列式数据库&＃xff0c;早期是我们采用的第三代时序存储引擎&＃xff0c;现在慢慢退居二线&＃xff0c;目前现在用来导入一些时序数据和高基数指标数据&＃xff0c;提供一些额外的数据分析能力。

Hickwall Portal&＃xff1a;

一站式的监控日志告警治理平台&＃xff0c;目前提供了指标接入&＃xff0c;指标查询&＃xff0c;告警配置&＃xff0c;通知配置&＃xff0c;日志接入&＃xff0c;日志管理&＃xff0c;机器agent治理等模块。

从存储集群来看&＃xff0c;TSDB Cluster的架构如下&＃xff1a;

1&＃xff09;总体架构分为三层结构&＃xff0c;vminsert写入层&＃xff0c;vmstorage存储层&＃xff0c;vmselect查询层。这三个组件都可以单独进行扩展&＃xff0c;并运行在大多数合适软件上。

2&＃xff09;写入层无状态&＃xff0c;支持多协议的写入&＃xff0c;写入层支持多协议&＃xff0c;包括InfluxDB&＃xff0c;OpenTSDB&＃xff0c;Prometheus&＃xff0c;Graphite等。接受程序写入的数据&＃xff0c;通过对metric&＃43;tag组合进行一致性hash写入到对应的存储节点&＃xff0c;当有存储节点失联&＃xff0c;会进行数据重路由分发到好的节点上面。重路由的过程中&＃xff0c;由于数据分发策略的变化&＃xff0c;可能会导致写入变慢&＃xff0c;等待存储节点倒排索引重建完成&＃xff0c;就会恢复写入速度正常。

3&＃xff09;存储层有状态&＃xff0c;采用shared nothing的结构&＃xff0c;每个节点数据不共享&＃xff0c;独立存储&＃xff0c;增加了集群的可用性&＃xff0c;简化集群的运维和集群的扩展。支持多租户&＃xff0c;采用了ZSTD压缩&＃xff0c;列式存储&＃xff0c;支持副本配置。

存储层的基本原理可以理解为存储了原始的数据&＃xff0c;并且会依据查询层发来的time range和label filter进行数据查找并且返回。在存储层&＃xff0c;针对时序数据做了很多存储优化。存储层要求配置一个数据保存的时间&＃xff0c;俗称Retention Period。Retention Period到期后&＃xff0c;会进行倒排索引的清理和重建&＃xff0c;cpu和io通常会大幅提升&＃xff0c;会影响写入效率。

从压缩来看&＃xff0c;压缩能够很好节省内存和磁盘空间&＃xff0c;时序数据的压缩特征比较明显&＃xff0c;TSDB Cluster采用先做时序压缩&＃xff0c;再做通用压缩的方法。比如&＃xff0c;先做delta-of-delta计算或者异或计算&＃xff0c;然后根据情况做zig-zag&＃xff0c;最后再根据情况做一次ZSTD压缩。据测试统计&＃xff0c;在生产环境中&＃xff0c;每个数据点&＃xff08;8字节时间戳 &＃43; 8字节value共计16字节&＃xff09;压缩后小于1个字节&＃xff0c;最高可达 0.4字节&＃xff0c;能提供比Gorilla算法更好的压缩率。

4&＃xff09;查询层无状态&＃xff0c;支持PromQL查询。

基本原理可以理解为进行查询语法解析&＃xff0c;从存储层获取时序数据并且返回标准的格式&＃xff0c;查询层往往会进行一些查询QPS&＃xff0c;查询耗时的限制&＃xff0c;以保证后端服务不被拖垮。

TSDB的部署架构图如下&＃xff1a;

 图6

六、未来规划

随着可观测性技术的不断发展&＃xff0c;仅仅局限于Metrics监控是不行的&＃xff0c;我们对未来的展望如下。

1&＃xff09;指标分级

指标管理没有优先级&＃xff0c;希望提供分级管理的模式。

2&＃xff09;云原生可观测性的探索

eBPF指标采集的引入&＃xff0c;提升主机端的可观测性能力。

3&＃xff09;Logging&＃xff0c;Metrics&＃xff0c;Tracing的结合。

多套方案交织&＃xff1a;可能要使用至少Metrics、Logging、Tracing3种方案&＃xff0c;维护代价巨大。在这种多套方案组合的场景下&＃xff0c;问题排查需要和多套系统打交道&＃xff0c;若这些系统归属不同的团队&＃xff0c;还需要和多个团队进行交互才能解决问题&＃xff0c;整体的维护和使用代价非常巨大。因此我们希望能够使用一套系统去解决所有类型可观测性数据的采集、存储、分析的功能。

4&＃xff09;兼容业界主流协议&＃xff0c;OpenTelemetry的标准。

OpenTelemetry旨在提供统一的可观测性数据收集&＃xff0c;未来服务端可以提供兼容OpenTelemetry协议的接入&＃xff0c;拥抱开源社区&＃xff0c;我们在保持关注中。

5&＃xff09;agent边缘计算&＃xff0c;前置数据聚合。

现在是服务端基于Flink做预聚合&＃xff0c;希望可以在agent端提供一些预聚合能力&＃xff0c;比如采集日志的agent能够聚合Metrics输出。

我们是携程技术保障中心系统研发团队&＃xff0c;主要负责携程私有云&＃xff0c;混合云和PaaS平台的建设&＃xff0c;管理数以万计服务器规模的集群&＃xff0c;负责数万台计算/存储混合部署和在线/离线混合部署&＃xff0c;支持海量数据的稳定存储。

团队积极拥抱开源和创新的软硬件架构&＃xff0c;在这里你除了可以学习到业界最流行最先进的技术&＃xff0c;还能接触到最新最酷的硬件产品&＃xff0c;我们长期招聘有志于从事基础设施方向并愿意深耕的同学&＃xff0c;目前容器/存储/大数据等方向都有均有开放职位。

简历投递邮箱&＃xff1a;tech&＃64;trip.com&＃xff0c;邮件标题&＃xff1a;【姓名】-【系统研发】-【投递职位方向】。

【推荐阅读】

• 高效线上问题排查——套路化和工具化

• 携程持久化KV存储实践

• 携程数据库发布系统演进之路

• 数万实例数百TB数据量&＃xff0c;携程Redis治理演进之路

 “携程技术”公众号

  分享&＃xff0c;交流&＃xff0c;成长